[Day 10] Spotify 的 Data Platform - Part 1. 資料蒐集的舊系統和資料延遲的問題

16th鐵人賽

Min

2024-09-24 21:21:06

221 瀏覽

分享至

終於把機器學習專案的生命週期介紹完畢啦！從今天開始，我們會介紹各大科技公司是如何實作之前介紹過的五個步驟，或是做了什麼事情來讓他們在建立專案的時後更加有效率又流暢。

為什麼認識這些很重要呢？這些大公司每天都需要處理上百萬、甚至上億筆的數據，他們的產品中也有數十個模型在同時運行。雖然我們接觸到的資料量可能沒有那麼大，但是如果能夠認識他們是如何有效地管理如此龐大的規模，勢必會有所助益的！得以讓公司內部的資料管理和使用流程變得更加便利，節省許多時間、溝通和管理成本。

今天，讓我們來聊聊 Spotify 是如何建立他們的 data platform 吧！

Spotify 作為一個資料驅動（data-driven）的公司，致力於利用高品質的數據做出決策和提供產品服務。

每當用戶在 Spotify 上進行任何操作，無論是聽音樂或是搜尋特定的音樂家，這些行為都會被記錄下來，送到資料庫中。而這些資料會被 Spotify 內部廣泛使用，例如用來分析他們 A/B testing 的實驗結果，進而優化他們的產品服務；另外，Spotify 的歌曲推薦系統、或是他們許多關於音樂的產品功能也都跟資料息息相關，因此好好保存這些行為資料是非常重要的。

Spotify 每天都需要處理約 1.4 兆筆數據，面對如此大量的規模，他們希望能夠更有組織且流暢地管理數據。因此，他們決定要建立一個資料平台（data platform）以滿足以下需求：

提供更容易搜尋和可用的數據
滿足財務報告的生成需求
確保數據的品質，以及可預測的結果
加速產品的開發速度

他們希望這個 data platform 能夠包含以下三種重要功能：

資料蒐集（data collection）：從不同來源蒐集資料到同一處
資料處理（data processing）：能夠有效又便利地管理所有資料處理的 pipelines
資料管理（data management）：確保資料的安全性跟完整性

圖片來源：https://engineering.atspotify.com/2024/04/data-platform-explained/

接下來，我們先來認識第一步——資料蒐集（data collection）是怎麼做的吧！

資料蒐集（Data Collection）

Spotify 將資料蒐集的系統稱為「事件傳遞系統」（Event Delivery System），我們會先介紹他們使用的舊系統，並說明舊系統的問題，最後介紹他們現有的新系統架構。

為什麼不直接講解新系統，而是還要花篇幅介紹舊系統跟他的問題呢？
因為，我覺得我們在設計一個系統時，一定會有各種點子，但是有些情境可能在設計時會被遺漏，真正發生時才發現系統的限制。因此，如果可以看看別人怎麼做的、發生了什麼問題、有什麼盲區是值得我們注意的，可能也可以避免我們走許多冤枉路吧！

舊系統

說到記錄用戶的行為資料，我們最直覺想到的就是將行為記錄在日誌（log）檔案中，Spotify 也不例外。他們舊有系統是基於每小時的日誌檔案的概念設計而成的。當使用者在 Spotify 的軟體上進行操作時，會建立一個事件，再將該事件寫入日誌檔案，並在每小時結束時將日誌檔案傳輸到 Hadoop 叢集（HDFS）上。

圖片來源：https://engineering.atspotify.com/2016/02/spotifys-event-delivery-the-road-to-the-cloud-part-i/

Spotify 舊系統的問題

這好像是一個非常直觀的架構，但是隨著 Spotify 的成長以及事件數量的增加，這個系統開始遇到穩定性和延遲方面的問題，維護系統也變得越來越困難且成本高昂。這個系統主要存在以下問題：

若 Hadoop 故障，則系統停擺：在舊系統中，如果 Hadoop 叢集故障，整個事件傳遞系統就會停擺。為此，Spotify 需要確保所有收集事件的服務器上有足夠的硬碟空間，並在 Hadoop 叢集恢復後盡快將所有資料傳輸到 Hadoop。這個過程非常耗時，又會造成資料延遲。
缺乏管理的靈活性：舊系統將所有事件都透過同一個通道傳輸，無法針對不同類型的事件進行不同處理。這件事也受限了他們的應用場域，若任何想要即時提供服務的系統，都需要接收所有事件，再過濾出他們感興趣的訊息。
小時結束標記問題：為了確保資料完整性，系統需要等待所有事件到達才能標記分割槽為「已完成」。接著，系統會開始進行一連串的資料處理 ETL 任務，以供後續的模型或其他服務使用。舊系統是仰賴生產者發送的「小時結束標記」來判斷一個小時的資料是否傳輸完成。然而，如果機器故障，它就無法發送結束標記，導致後續 ETL 作業會無限期地等待，除非進行人工干預。隨著機器數量的增加，這個問題會變得更加嚴重且難以處理。
資料完整性和延遲的問題：承續上一點，如果在標記為「已完成」之後，該小時分割槽的資料發生任何變化（例如，由於網路延遲而導致事件遲到），則下游作業將無法處理這些更新後的資料。因此若發現有延遲資料，唯一的方法是手動停止所有受影響的下游作業，並重新執行所有作業，以處理更新後的資料。這個過程非常耗時且容易出錯，需要大量的人工介入。